NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/networking/3356

Internet Message Format | 1996-08-05 | 21.1 KB

Path: cs.uwa.edu.au!jasonb
From: [e-mail] (Jason S Birch)
Newsgroups: comp.sys.amiga.networking
Subject: Re: Announce: AWeb 1.0 released!
Date: 2 Apr 96 06:31:41 GMT
Organization: The University of Western Australia
Message-ID: <[e-mail]>
References: <4iva78$[e-mail]> <4j1f6e$[e-mail]> <[e-mail]> <4j8o6r$[e-mail]> <[e-mail]> <4jaue8$[e-mail]> <[e-mail]> <4je3qj$[e-mail]> <[e-mail]> <4jgdfr$[e-mail]> <[e-mail]> <4jh986$[e-mail]> <[e-mail]> <4jjcc7$[e-mail]>
NNTP-Posting-Host: decadence.cs.uwa.oz.au
X-Newsreader: NN version 6.5.0 #3 (NOV)

[e-mail] (Michael van Elst) writes:
>But why should every single program manage priorities when there is
>a more easy solution ?

Firstly, not every single program needs to do it -- only a program
that wants to do some heavy computation and still interact with the
user. The best way to do that is create a thread, and if you're
creating a thread anyway you may as well use a value other than "0"
for the priority when you call CreateNewProc() (or others), right?
This benefits the user because the computer doesn't needlessly feel
sluggish, and all interactive programs benefit whether they're MUI
programs or not. Yes, MUI programs benefit more. But all interactive
and I/O bound programs benefit some, and some is better than none.

Secondly, this allows a much simpler programming model for MUI that
doesn't require locking and semaphore protecting of all data
structures just to use the OO mechanism.

>But MUI classes defer everything
>to the application. The right way is to defer only the slow operations
>to the application (or another low priority task).

What you propose is for some MUI attributes to be modifiable by
input.device, and/or some MUI methods to be callable by input.device.
Currently they are not -- only *one* thread may do MUI stuff, which
greatly reduces the complexity of programming MUI classes.

>Programmers that _use_ a GUI toolkit do not care about this. Programmers
>of new classes have to care.

Programmers of MUI are supposed to use an OO paradigm. That means
creating custom classes for everything, rather than simply writing an
iterative program that uses a GUI toolkit. It also means that writing
custom classes should be easy, so the OO mechanism itself should not
require you to deal with the possibility of multiple contexts
executing your class.

>ClassAct doesn't make it easier. It isn't actually difficult.

I haven't used ClassAct, I was merely repeating a claim I think one of
the developers of CA made when it was first released.

>Programmers that use the toolkit do not have care about any internals
>and programmers of new classes have to know the internals of the toolkit.
>There is no difference.

The "internals" in this case are the details of the OO mechanism,
BOOPSI. All you need to know is how to register a new class and its
dispatcher, and how to receive methods -- just the basic BOOPSI stuff
(although it's simplified a bit by some MUI glue routines). You don't
have to worry about locking of structures or anything like that,
because you're guaranteed never to have more than one context ever
sending methods to your class. Enabling different contexts to send
methods (such as input.device telling you to draw yourself in a
depressed state) would require you to be aware of these issues.
Remember, MUI is completely general in that a class can respond to an
activation in any way it sees fit, and *any* attribute of *any* class
can have a notification set on it.

>>No -- because the OO system *itself* doesn't run at different
>>priorities.

>I am sorry. You have some wrong ideas about what "the OO system" is.
>MUI uses BOOPSI too, the OO system does run at the priority you use it
>at.

I am sorry, but I think *you* are not understanding what I'm saying.
The OO system is BOOPSI. The OO system itself (under MUI) doesn't run
at different priorities. The OO system does run at the priority you
use it at. All these are compatible, unless for some reason you think
MUI uses BOOPSI under anything other than the app's context, in which
case you'd be wrong.

>>Within a custom class, the OO mechanism is still running on
>>the same context as the rest of the classes.

>No. If you invoke a method from the user's program the priority isn't
>suddenly changed and the method is not executed by input.device.

This is correct, and is entirely consistent to that which you just
said "No" to.

>>Any method you call, any
>>attribute you set, is all still on the same context.

>Sorry, this is completely wrong.

Sorry, but it is completely right. But I know why you think it's
wrong:

>As I said, MUI uses the same OO mechanism as gadgetclass.

Yes, MUI and gadgetclass both use BOOPSI. However MUI is *not*
subclassed from gadgetclass. MUI's Notify class, superclass to all
others, is directly subclassed from BOOPSI's rootclass, and therefore
has nothing to do with Intuition gadgets. There are a long list of
reasons for wanting to do this, with the only downside being that a
handful of classes which would be simple enough to refresh under
input.device without too much penalty to the system do not get
refreshed there.

It's funny, but I'm sure I saw you complaining about this last year,
so I assumed you knew it. Hmm... Perhaps it was someone else.

>>Within those other contexts, you
>>can't call methods and set attributes of other objects directly.

>This is wrong. Of course you can do this.

No, you cannot. You are not allowed to send methods and set attributes
to/of MUI objects unless they are on the same context. There is only
*one* exception to this, MUIM_Application_PushMethod, which allows you
to give the application object a method you want processed when it
gets around to it, and *it* deals with all the issues of locking and
multiple contexts for you, so the class designer doesn't have to.
Remember, designing classes is meant to be easy.

>In fact, even simple
>gadgetclass objects are created and configured on the application
>context, event handling and refresh are done on input.device context.

Yep -- gadgetclass objects do that alright. You're right on the money
there. MUI objects, however, are not gadgetclass objects.

>The methods do not run at pri 20 by default. And if you look at
>datatypes (which are just special versions of gadgetclass) you see
>that these can offload operations to a separate task or to the
>application (by sending a sync message).

Yes. And look at what happens when the programmer isn't being *very*
careful -- AmigaGuide.datatype and Grapevine's scrolling text display.
If you leave it up to the programmer and they make a mistake (which is
easy enough), you can wind up with jerky mouse pointers using that
system. At least with MUI the worst that can happen is a sluggish
application. The rest of the system is fine.

>Because you cannot ensure that the event handling loop is always
>ready and waiting. Another task at default priority can slow down
>your loop. There is no way to change that but to control priorities
>of all tasks.

Well, there is another way -- each MUI program could run its event loop
at pri 1. :-) However that's not necessary. As I said, the worst that
happens is the app becomes unresponsive, and that can be fixed simply
by the user or the programs responsible or something like Executive
running CPU intensive tasks at a lower priority. I do that *anyway*,
regardless of MUI, because I don't like my interactive programs to
become needlessly sluggish. It's not a big enough problem to want to
give up the simplicity and generality of OO programming under MUI's
current implementation to remedy.

>On the other hand it is simple to rely on input.device to run at pri
>20 ahead of all other tasks.

Sure -- and get frozen mouse pointers when you screw up, have locking
problems associated with two different threads of execution running
through your custom classes, or having special cases for a few simple
gadgets that can be cheaply refreshed by Intuition, etc.

>>That's right -- the *programmer* is left the task of offloading
>>expensive operations,

>No. If you use MUI _then_ the programmer is left the task of offloading
>expensive operations. With datatypes this is done by the datatype
>itself.

At least with MUI, when you *do* spawn a task, it's entirely under your
control. It has nothing to do with MUI, it will never be touched by
MUI, it is a simple, normal, subtask. As I said, the subtasking has
nothing to do with your OO system, which keeps the OO system simple.

>>A complex AmigaGuide document can stop my mouse pointer
>>moving for a second or more.

>As I said this is a flaw in the AmigaGuide datatype.

Yep. Even a professional programmer at C= can make a mistake. Imagine
if the programmers of all those MUI programs on Aminet were exposed to
the same difficulties...

>Or use a sensible scheme in your GUI toolkit so that this isn't a
>problem.

"Sensible" in this case is obviously very much a matter of taste. I'd
rather something that was simple, uniform, and completely general with
no special cases and "gotcha"'s.

>>Running
>>CPU intensive processes at pri 0 *will* make the machine feel slower.

>That's why you do not want to run the GUI at this priority.

*NOT* just the GUI. Making 'ls' eight times slower by running just two
tasks isn't helped by a pri 20 GUI.

>>You *will* notice the effect in your text editor.

>But you do not have to notice this in your GUI.

Nope, the GUI will depress buttons fine. But the delay in characters
appearing that you have typed will more than compensate. That delay
won't exist if the CPU intensive stuff is at a lower priority.

>>You *will* notice
>>that, while a button still depresses instantly, the application takes
>>longer to respond.

>That's obvious. If the machine is busy then it becomes slower.

It needn't. If I run 20 CPU intensive processes at pri 0, the machine
is practically unuseable. Anything doing lots of I/O will lose out in
a large way. However I have run over 400 CPU intensive processes at
pri -10 in the past (before I ran out of memory) and apart from the
lack of memory, you wouldn't even know they were there (except new
process creation was slow).

Running interactive stuff at a higher priority doesn't cause the CPU
intensive stuff to miss out on any cycles they would've got anyway.
But running CPU intensive stuff at the same priority has a huge impact
on the interactive stuff, which keeps giving up portions of their
quanta and waiting their turn again.

>>Watch your text editor also become sluggish.

>This depends on your text editor. A text editor based on BOOPSI code
>wouldn't become sluggish.

You're saying that characters be processed and displayed as they are
entered, on input.device's context? Cut and paste? Reformatting as you
type? Online spell checking? The text editor probably won't be
sluggish, but I bet your pointer sure becomes jerky and you'd want to
avoid using your serial port for anything important.

>>It isn't responsive if (gasp) I run another CPU intensive task at
>>priority 0,

>It is more responsive than a MUI application under the same condition.

Yes. You are perfectly correct. Does that mean all apps should
"suffer" because it "hurts" MUI more?

>>or if it's coping with many connections and image
>>decompressions while I'm trying to scroll through a large document.

>Overloading a machine is never fast and changing priorities won't
>change that.

Of course it does. I suggest you try it sometime. Remember, AmigaOS
isn't like Unix.

(As an aside -- using more threads, thanks to Exec's scheduler, will
actually make your program relatively *faster* in a heavily loaded
environment. Run 10 CPU intensive tasks, compare two programs A & B
which do the same thing. A uses one thread, B uses 10. B will get
about 1/2 the CPU in total, A will get about 10%. Guess which will go
faster...)

>Sure. But with Executive the various CPU intensive tasks do not
>timeslice any longer (a 1 second timeslice is ridiculous).

Of course, as Petri has said, this can be reduced by reducing the
number of priority levels in use, and (apparently) the registered
version does more to ensure more tasks run at the same pri -> normal
Exec scheduling for those tasks.

>>Many programs (eg. Real3D, IBrowse) spawn subtasks to do CPU intensive
>>tasks. (Note that *only* CPU intensive programs need do this, other
>>"standard programs" make no difference.)

>I'm talking about close to any program. Even DIR or LIST have to
>change priorities fore and back because they possibly sort the output.
>Evey standard ANSI C program would have to be modified.

Don't be rediculous. It's only a problem if the CPU intensive operation
goes for long enough for the user to switch to another, interactive,
task, and say "Oh, boy, this is unresponsive". Things like 'dir' or
'list' typically don't fit into that category, and even if they did and
the user didn't want to run Executive, they could simply run their
shells at a lower priority than 0. Alternatively, MUI programs could
run at 1 (I notice GoldEd does this. It's a lot better than 20, if you
ask me).

>Now what is easier, especially when you think that Intuition and the
>console is based on the second model and the fact that most programs
>that require interactive responsiveness use Intuition ?

Umm... Let me think. I would say the easiest way would be to do it
like AmigaGuide.datatype does it? Am I wrong? Has the
AmigaGuide.datatype actually done it the hard way?

From the programmers point of view, an OO system that doesn't
*require* the programmer to worry about multiple contexts calling his
custom class, and provides a consistent and complete mechanism for all
classes, sounds like the simplest way to go. If they *do* decide to
run a separate thread (which they should do if they're going to be
waiting some time before processing user input and not put the
application to sleep), then it doesn't make any difference to use a
"-1" for its priority instead of "0". The thread doesn't know anything
about MUI, MUI doesn't know anything about the thread. Sounds -- and
is -- pretty simple.

>But you do care wether AWeb presents you a page while loading or
>wether Executive prevents this.

The page was presented while loading. AWeb simply didn't respond to
input. A special entry in Executive fixed this. IBrowse also presents
a page while loading and responds to input, with or without Executive.
It didn't need a special entry.

>But it makes a difference when the process is important and not
>only the completition of the process.

But it won't be starved of CPU by the event loop, now, will it?
Remember, I was suggesting run *all* CPU intensive subtasks at the
same, lower priority. The event loop doesn't take much, and you want
that to get the CPU immediately whenever you click something, anyway.
I can envisage an example (although IBrowse and AWeb don't apply)
where you have multiple processes (eg. playing separate animations)
that need to be timesliced quickly to appear they are all running at
once. If you were running Executive you would probably want to use one
of the better schedulers or make a special entry in this case.

>But which is a wild guess. In case of AWeb or other programs that
>are interactive _and_ need CPU time you lose.

Not if they spawn lower priority subtasks for the CPU intensive stuff.
AWeb already spawns subtasks, they're just at the wrong priority.

>>Are you
>>happy waiting 4 seconds for an 'ls' that *could* have been finished in
>>0.5? Just because *two* other tasks are running?

>Are you complaining about AWeb not displaying a page while loading ?

Did you read my post? AWeb displayed a page while loading fine. It just
didn't respond to user input. The page layout thread (whatever that
was) was getting plenty of CPU -- as the page was quickly being
displayed -- but the clicks on the gadgets went unheeded until the page
was finished 2 1/2 minutes later (although, I'm sure you'll be pleased
to know, they *were* refreshed alright).

No, my example had nothing to do with AWeb. The point, as I hoped was
obvious, but that you've totally failed to respond to, was how
desireable offloading CPU intensive code to a low priority task is. You
claim MUI is the reason for wanting this and you don't need it
otherwise. The 'ls' example shows a real-life, non-MUI example of just
what happens under AmigaOS when you try to run CPU intensive tasks at
the same priority as I/O bound tasks. No other tasks, 0.5 seconds for
the 'ls'.  Two other tasks, 4.0 seconds for the 'ls'. Eight times
slower. No MUI. Ten other tasks, priority just below the 'ls' task,
0.5 seconds. This applies to any task doing I/O -- they keep giving up
their quantums before they're finished, losing out on their fair share
of the CPU pie. They can't save it until later. Exec's scheduler is
deadly for I/O bound tasks under a heavy load.

>If it lasts 157 seconds then there is a need for another task (or at
>least a heavy busy sign).

Ah, I'm glad you agree, then. A busy sign isn't desired, because AWeb
is meant to be able to allow you to click on a link on the page as
it's displayed (which it does now that I've told Executive to put AWeb
and all it's childtasks at a fixed priority). For some reason, the
data was being transferred, images decoded, page layed out and
displayed, all perfectly -- with the one small problem that no user
input was processed while Executive was fiddling with priorities. Weird.

>But then I haven't seen anything like that
>and I wonder how a 600k page (which is silly btw) can take so much
>longer than the 50k pages that I have seen.

If the page layout algorithm has worse than linear complexity it could
easily happen. However, I've just done some tests, and it certainly
appears linear: 48k, 12s; 96k, 24s; 192k, 50s; 384k, 103s. This is
consistent with 157s for a 600k page. Are you getting much less than
12s for 50k pages (this is across ethernet, BTW)?

>You can only stop network activity.

That's a shame. I'd prefer it to progressively display pages as it got
them from the cache, like it does when transferring them across the
network. Then I could click on them or go somewhere else without
having to wait for it to finish. Currently it just locks up until the
page is ready to be displayed.

>IBrowse becomes sluggish without Executive too.

Yes, if you're running other CPU intensive tasks at the same priority.
(If not, it doesn't, because it's own CPU intensive tasks run at a
lower priority.) So does an 'ls'. Even more reason for asking
programmers to offload CPU intensive stuff to a lower priority,
don't you think? I'm not saying MUI *isn't* affected, I'm saying lots
of things *are*. Not just MUI, and in the case of 'ls', some worse
than MUI.

>I do not blame it on Executive and MUI. I say that MUI requires
>Executive or changes in almost every program. And I do not want to
>change almost every program just to keep MUI happy. I'd rather use
>something like MUI that does not require me to change these programs.

MUI requires the same thing the 'ls' and the text editor does --
programmers to use lower priorities for CPU intensive stuff, if the CPU
intensive stuff is going to take long enough for the user to want to do
something interactive in the meantime. The vast majority of programs do
not fit into this category. A few do. Decoding images in a web browser
can take a while, and the user is likely to want to scroll the document
while they're waiting, so it makes sense to offload that to a lower
priority. IBrowse does. AWeb would benefit from it too, regardless of
whether MUI is used or not. It *would* make it respond quicker to user
actions (where "respond" doesn't just mean "make the button depressed",
but also means *do what the user wants* -- like follow a link).

It really doesn't seem like a lot to ask, especially since he *is*
already spawning off several threads to deal with different tasks.

>And running interactive tasks at a high priority does the same and
>was done by Intuition - to some degree - all the time.

It does *not* make the apps more responsive. *All* it does is make a
few gadgets visually respond quickly. The apps themselves will take
longer to process your input -- whether it be typing, or clicking on a
WWW link, or telling it to stop loading a page -- and all of it
unnecessary!

>I'm not happy
>if I had to change this and many other programs where you require
>them to spawn off CPU intensive work to other tasks.

Fine. I'll just run them at a lower priority, like I'm doing now with
AWeb. The other apps in the system will still be responsive, only those
ones will feel sluggish. I'd just prefer that they didn't feel
sluggish, either.

>Going the other way round is much easier and doesn't require changes.

Going the other way round doesn't do programs like 'ls' much good.
MUI programs are just one class of program to benefit, and by no means
the only ones.

>                                Michael van Elst
>Internet: [e-mail]

--
Jason S Birch                        ,-_|\ email: [e-mail]
Department of Computer Science      /     \ Tel (work): [phone]
The University of Western Australia *_.-._/ Fax (work): [phone]
Nedlands  W. Australia  6907             v  Tel (home): [phone]